回顧

筆者直到到半年前為止，開發的內容幾乎是圍繞在平台的部分，後來才踏入遊戲這塊。

平台與遊戲著重的業務處理，明顯有不同的重心，因為平台的業務處理重點在於資料，久而久之可能也不小心養成了定性思維，定性的抽象方式。

平台是這樣的，API request進來後，先驗參數，若參數格式，打回票。如果成功進來，大概就是開始一連串的資料加工，來舉筆者之前某個上傳excel名單處理的功能作範例好了。

處理邏輯大概是這樣:

1. 檢查這份excel格式對不對，大小有沒有超過上限。
2. 開始檢查這些名單上的id，發某某API X取得他們的詳細資料。
3. 資料驗證這些id，是否有效或者有資格出現在這份名單。
4. 從資料庫撈取關聯的資料，根據這些id作邏輯處理加工。
5. 從某某API A撈取資料後，再加工。
6. 從某某API B撈取資料後，再加工。
7. 根據加工後的資料，製作需要格式，發某某API作處理。
8. 根據加工後的資料，製作需要格式，寫入某某DB作處理。
9. 以上每個步驟斟酌寫log，結束。

每次的工作都幾乎是在處理資料，如何把資料怎麼處理，資料結構怎麼設計，怎麼跑運算效能會比較好，怎麼檢查資料才不會錯誤，一直以來都是這樣很類似的工作，怎麼在這之上，能夠抽像出更好的程式設計，其實非常欠缺示範，大家每天被資料、資料、資料的念頭深深綁架著。

開始學golang之後，筆者一直在反思，為什麼物件導向學了那麼久，寫出來的程式卻總是外形有像，內在卻不行。interface 用了那麼久了，卻總好像只有理論而已。

況且golang已經是另外一種設計思考模式的程式語言，雖然它開宗明義，擁抱OO的概念，但不是OOP，自己又如何更成長一步呢?

改變

不斷的練習總結和歸納，筆者認為是很有幫助的，從小到大，從細部處理好，再到局部，再到全局。

以設計程式來說，可能一開始我做的只會抽出某一種行為，譬如說，發API拿到id代表的人名、詳細資料。

可能就寫個function，叫做『getUserData()』，然後可能有些更細部的處理拆分，譬如說『getUsersAPI()』『resAPIDataRebuild()』等等。

過去以來，筆者寫了這類堆積如山的function出來，都不敢叫它『method』，因為『method』是有個主體的function，才叫做『method』。

縱使這些東西前後有連貫的function，放到同一支檔案，或同一個資料夾，也難以視為一個主體，因為難以簡單輕鬆了解它的範圍。

那主體怎麼界定?以前php一直在寫的就是class，以golang來說，就是struct。

這可能是廢話，尤其當你只是把它當做某種類型資料的資料存放，裡面的method只是根據你的需求設計的運算。

但是，練習著用『業務』的概念來想，設計主體的想法就會跟以前不一樣。

以上一篇的例子來說，employee(員工)和Tool(工具)就要拆分出兩個清楚、而且沒有直接瓜葛的主體，互相不干涉對方應該要處理好的業務，甚至，連對方實際規格，實際長怎什麼樣子都可以不用了解，只要界接的input和output對，誰都可以界接。

想想各主體要負責的部分，每個主體想想要別人提供什麼結果，自己要提供什麼結果，以此思考方式建構出程式每個部件，會發現跟以前用『資料』的方式思考寫出來的程式，完全不一樣。